1. Field of the Invention
This invention relates to database integrity management procedures for multiple concurrent transaction processing systems, and more particularly, to a method for concurrent record updating within a single data Control Interval or block without lock contention at the block level.
2. Discussion of the Related Art
The lock manager portion of an operating system in a multiprocessing environment assigns and reassigns locks on storage resources on behalf of processes. This locking activity ensures proper transaction serialization and database integrity, but may lead to a decrease in process concurrency. Data processing throughput can fall when the lock manager frequently locks a resource having a high concurrency requirement arising from many concurrent processes operating with the same resource. This lock contention situation requires the lock manager to allocate such a resource among the concurrent processes. Moreover, many of the processes are slowed by the wait states imposed to sort out the lock contention. The lock manager must also consume processing time to lock, unlock and resolve wait and resume conditions.
Because a relational database management system operates with concurrent processes in a multiprocessor database environment, it uses facilities such as lock managers. The present state of the art can be appreciated by reference to C. J. Date, "A Guide to DB2", Addison-Wesley Publishing Co., pp. 191-195 (1984); and C. J. Date, "An Introduction to Database Systems", Addison-Wesley Publishing Co., pp. 422-427 (1986). Refer also to H. F. Korth, et al, "Database System Concepts" McGraw Hill, Inc., pp. 356-402 (1986), for a general discussion of concurrency control in database systems.
In multiprocessing systems generally, and database management systems in particular, when one user accesses a file for editing or updating purposes, all other users are locked out until the accessing update is completed or committed. To improve concurrency in a shared file environment, multiple users should be permitted to read a file that is being concurrently updated. Also, one user should be permitted to update records in the same file in which another user is updating different records.
Practitioners in the art have suggested many methods for improving concurrency in database systems. In U.S. Pat. No. 4,716,528, Richard A. Crus, et al disclose a method that typifies such hierarchical locking and lock promotion techniques with the variable granularity that can manage the trade-off between lock processing overhead and concurrency. Crus, et al teach the use of a coordinated pair of locking limits where a first limit is placed on the number of "small granularity" locks per resource and a second limit is placed on the total number of locks assignable to each process. When the "small" lock limit is breached, their method withdraws all small locks and grants a single global lock to the entire resource (lock escalation), thereby reducing the total number of locks. When the process requests an additional lock over the total lock number limit, the lock is refused. However, Crus, et al do not suggest a technique of constant granularity (and, thus, low overhead) for avoiding lock contention at the block level during concurrent block access.
In U.S. Pat. No. 5,043,876, Charles R. Terry discloses an N-level file shadowing technique for use in a shared file environment. Terry maintains N-level shadow copies of each shared file to allow multiple users to read a consistent copy of the file even though other users may be simultaneously updating the same file. Every reader who opens the shared file sees the latest committed copy of the file and is unaware of updating transactions occurring after the file is opened. However, Terry permits only one updating transaction at a time, forcing other concurrent updating processes to wait because of update lock contention at the file or block level.
Although the locking contention and concurrency problem is keenly felt in the art, no teachings or suggestions are recorded for managing the concurrent accession of common data blocks containing multiple records in shared memory by record-level locking alone. That is, access by two or more concurrent updating transactions to the same block or data Control Interval (CI) normally requires locks at the data CI level, as taught by Terry and others. There is a strongly-felt need in the art for a method permitting concurrent access to a single block by two or more updating processes with serialization by record-level locking alone. The related unresolved problems and deficiencies are keenly felt in the art and are solved by the present invention in a manner described below.
3. Glossary of Acronyms
The following acronyms are used herein as defined below and may be appreciated with reference to the incorporated reference, this detailed specification and to any suitable IBM system manual, for example, "MVS/ESA VSAM Administration Guide" SC26-4518 International Business Machines, Inc., Armonk, N.Y., and Marilyn Bohl, "Introduction to IBM Direct Access Storage Devices" Science Research Associated, Inc., Palo Alto, Calif. (1981):
API Application Programming Interface PA1 BMF Buffer Management Facility PA1 CA Control Area PA1 CI Control Interval PA1 CI/CA Control Interval/Control Area PA1 CIDF CI Definition Field PA1 KSDS Key-Sequenced Data Set PA1 PB Private Buffer PA1 RLS Record Level Sharing PA1 RMR Record Merge Redo PA1 RPL Request Parameter List PA1 SDSH Shared Data Storage Hierarchy PA1 SES Structured External Storage PA1 SLC Shared Local Cache PA1 TLCE Test Local Cache Entry PA1 UOW Unit Of Work